深入剖析IIS 6.0（上）
　　關於IIS 6.0的故事一言難盡，如果你已經在IIS技術上有所投資，IIS 6.0無疑是一個動人的、非聽不可的話題。鑒於IIS 6.0和以前版本的差別實在太大了，只用一篇文章很難做到面面俱到，所以本文首先探討IIS 6.0的安裝、體系結構以及由於體系結構方面的差異帶 來的全新服務功能，下一篇文章接著介紹IIS 6.0的新特性——其中有些你可能還沒有聽說過，另外還
-->
有默認配置方面的一些重要變化，這些變化可能會影響到你的遷移計畫。  

　　一、安裝IIS 6.0
　　首先從最基本的說起吧。IIS 6.0包含在Windows Server 2003伺服器的四種版本之中：資料中心版，企業版，標準版，Web版。另外，順便再回答一個最常見的IIS 6.0問題：IIS 6.0不能在Windows XP、2000或NT上運行。
　　安裝好Windows 2003之後，馬上就可以看到Windows 2003/IIS 6.0的與眾不同之處，其中一個關鍵的變化是，除了Windows 2003 Web版之外，Windows 2003的其餘版本默認不再安裝IIS。按照微軟過去的理念，安裝作業系統的同時IIS也自動啟動，為許多Web應用提供服務，Windows 2003的做法可謂一大突破。在Windows 2003中，安裝IIS有三種途徑：利用“管理您的伺服器”嚮導，利用控制面板“添加或刪除程式”的“添加/刪除Windows元件”功能，或者執行無人值守安裝。
　　第一次啟動Windows 2003系統時，“管理您的伺服器”嚮導自動啟動，如圖一所示。

圖一

　　選擇“添加或刪除”角色，在“配置伺服器”嚮導中可以看到一系列可配置的伺服器角色，其中就有“應用程式伺服器（IIS，ASP.NET）”選項，如圖二，選中該選項之後點擊“下一步”，嚮導提供了是否安裝ASP.NET和Microsoft FrontPage伺服器擴展的選項。可以看到，微軟在這裏採用了一種新型的“安裝任何部件之前總是
-->
徵求用戶意見”的IIS安裝策略，對於微軟來說，這是一個徹底的轉變，證明微軟確實在認真對待安全問題。  

圖二

　　使用控制面板中的“添加/刪除Windows元件”功能還要靈活一些。在嚮導中選擇“應用程式伺服器”，再點擊“詳細資訊”，嚮導顯示出一系列元件的清單，其中就有“Internet資訊服務（IIS）”選項，還有一些選項是以前的“添加/刪除Windows元件”嚮導沒有提供的，表一概括比較了IIS 6.0和IIS 5.0 的主要組件。如果從這裏安裝IIS 6.0，最後得到的Web伺服器可能只支援靜態內容（除非在安裝期間選中了某些擴展組件）。選中Internet資訊服務選項，再點擊“詳細資訊”，可以看到IIS 6.0的子組件，如圖三所示。

圖三

 

表一：IIS 6.0和IIS 5.0元件比較
IIS 6.0	IIS 5.0
應用程式伺服器	Internet資訊服務
應用程式伺服器控制臺	公用文件
ASP.NET	文檔
啟用網路COM+訪問	檔傳輸協定（FTP）服務
啟用網路DTC訪問	FrontPage 2000伺服器擴展
Internet資訊服務	Internet資訊服務管理單元
後臺智慧傳送服務（BITS）伺服器擴展	Internet服務管理器（HTML）
BITS管理控制臺管理單元	NNTP
BITS伺服器擴展ISAPI	SMTP
公用文件	萬維網服務
檔傳輸協定（FTP）服務
FrontPage 2002伺服器擴展
Internet資訊服務管理器
Internet列印
NNTP服務
SMTP服務
萬維網服務
Active Server Pages
Internet資料連接器
遠端管理（HTML）
遠端桌面Web連接
在伺服器端的包含檔
WebDAV發佈
萬維網服務
消息佇列
Active Directory集成
公用
下層用戶端支持
MSMQ HTTP支持
路由支持
觸發器

 
　　也許你已經注意到了表一列出的某些新增元件選項，但你注意到IIS 6.0少了什麼嗎？IIS 6.0中消失不見的最主要的一個項目是文檔。在IIS 6.0中，所有文檔都以幫助檔的形式發佈，不再有IISHelp虛擬目錄。在IIS 5.0中，如果從本地訪問伺服器，默認Web網站自動打開IIS的文檔，但在IIS 6.0中，如果打開“
-->
http://localhost”，只能看到一個聲明網站正在構建之中的頁面。  

　　另外，在IIS 5.0的IISHelp虛擬目錄中有一些錯誤處理頁面，這些錯誤處理頁面以ASP的方式實現。如果你要用到定制的（或者修改過的）幫助檔、錯誤處理頁面，在IIS 6.0網站上必須自己創建該目錄。
　　進一步分析IIS 6.0的子元件清單，可以發現：原來在IIS 5.0和IIS 4.0中默認安裝的Internet服務管理器（ISM）已經不見了。但是，如果你點擊“萬維網服務”（IIS 6.0的子組件之一，但圖三沒有顯示出來），再點擊“詳細資訊”，可以發現IIS 6.0的萬維網服務還有子元件，如圖四所示，其中包括原來的Internet伺服器管理器，不過現在已經改名為“遠端管理（HTML）”；還有Windows 2003和XP版本的終端服務高級用戶端（TSAC）——現在它叫做“遠端桌面Web連接”。現在，我們不僅可以方便地添加或刪除這兩個子元件，對其他子元件也一樣，包括：ASP，Internet資料連接器，在伺服器端的包含檔，WebDAV發佈，當然還有萬維網服務。

圖四
　　安裝IIS 6.0的最後一種方式是無人值守安裝。和以前一樣，這仍舊是唯一一種能夠將工具和默認Web網站安裝到其他驅動器（而不是系統驅動器）的安裝方式。Windows 2003無人值守安裝方式大體上仍和Win 2K一樣，都是用Sysocmgr和一個應答檔實施安裝。當然，新的特性需要新的參數、選項，有關這方面的詳細說明，可以在Windows 2003 Release Candidate 2 （RC2）找到，地址是：http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/datacenter/gs_installingiis.asp。
　　如果將IIS 5.0或IIS 4.0伺服器升級到Windows 2003，IIS 6.0不會被設置成自動啟動。也就是說，如果採用升級的方式安裝，IIS 6.0默認是禁用的，除非遇到下列情況之一：
　　⑴ 以前的IIS伺服器上已經安裝了IIS Lockdown工具。
　　⑵ 存在註冊子鍵
-->
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\RetainW3SVCStatus，且它包含一個任意的註冊鍵。例如，你可以創建一個名為EnableIIS6的鍵，設定它的值為DWORD類型的1。
　　⑶ 在無人值守的升級安裝中，應答檔的[InternetServer]部分存在DisableWebServiceOnUpgrade = True/False條目。
　　二、支援服務
　　自IIS 6.0發佈以來，它的某些新特性一直是人們關注和議論的焦點，成為眾人矚目的明星，但另一些Internet支援服務雖然不是經常有人說起，卻同樣值得關注，其中之一就是POP3服務和POP3服務Web管理器。我們無從得知微軟為何不在“應用程式伺服器”元件清單中列出POP3服務，但是繼SMTP服務之後（SMTP服務隨同POP3服務一起安裝），管理員們盼望POP3服務已經很久了，他們一直在期盼著用一個簡單的POP3服務來替代龐大的Microsoft Exchange Server。
　　統一描述、發現和集成協議（Universal Description, Discovery, and Integration，即UDDI）服務是Windows 2003提供的又一種新的功能，它也與IIS有關，但默認不安裝（注意，Windows 2003 Web版不能安裝UDDI）。UDDI是一種產業標準（即不是微軟的發明），能夠通過廣告發佈IIS伺服器提供的Web服務——這裏“廣告”一詞的含義與日常生活中的廣告不同，它是指一種讓客戶程式（通常是Web流覽器）獲知Web服務（通常是ASP.NET應用）各種細節的方式。UDDI仍在發展之中，但一些企業已經在內部採用UDDI，以便開發者將自己的代碼發佈給其他協作開發的人。有關UDDI的更多知識，可以在下列網站找到：http://www.uddi-china.org/（中文），http://www.uddi.org（英文），http://www.uddicentral.com（英文）。
　　最後一種重要的支援服務是後臺智慧傳送服務，即 Background Intelligent Transfer Service或BITS。BITS是一種後臺檔傳輸機制和佇列管理器，也稱作節流傳輸服務。BITS控制檔請求，減少帶寬消耗並改善最終用戶的體驗。針對IIS啟用BITS可保證Web伺服器的服務品質，如果沒有BITS，當100個用戶同時下載一個500 MB的檔，伺服器的帶寬可能就被消耗殆盡，導致其他訪問Web服務的用戶頻繁地遇到超時錯誤。如果BITS就象廣告說的那樣有效，可以料想它將是一種非常實用的服務。Windows 2003發佈之後，按照計畫，BITS還將移植到Win2K上。關於BITS的更多資訊，請參見http://www.microsoft.com/windows.netserver/techinfo/overview/bits.mspx。
　　三、全新的內核
　　從體系結構上看，IIS 5.0和IIS 4.0其實是一樣的：它們都是在用戶模式下運行的發佈Web內容的應用程式，或者在Inetinfo進程之內以System帳戶運行，或者在Inetinfo進程之外以IWAM用戶運行。雖然在較重的負載下，IIS 5.0也有相當出色的表現；不過從IIS 6.0開始，我們對IIS底層結構的看法應該改變了。為了使IIS不僅能夠輕鬆地支持1000個Web網站，而且能夠支持10000個甚至更多的網站，同時還要提高Web伺服器的安全性和可靠性，微軟放棄了原有的IIS內核，重新構造了一個。
　　另一個促使微軟重新構建IIS內核的原因是，微軟（以及其他廠商）認識到，Web伺服器的性能和可靠性問題絕大部分是由於品質低劣的Web應用造成。IIS 5.0通過帶緩衝池的Out of Process容器減輕這類問題。在IIS 5.0中，在Out of Process池中運行的應用一旦崩潰，一般不會波及到IIS本身，因為應用程式在Inetinfo之外的進程中運行，但運行在Out of Process池之內的所有Web應用都會終止——在默認情況下，所有的應用程式都在該池之中運行。在這種情況下，排解故障很不容易，因為要確定哪一個應用程式導致了問題非常困難。IIS 6.0將監聽請求、創建和監視Web網站、運行Web服務這些不同的任務隔離了開來，這一新型體系可望解決IIS 5.0存在的問題。從理論上看，新的體系將極大地改善可用性、安全和性能；從實際情況看，根據微軟和Beta測試者的報告，新的體系令穩定性和性能有了奇跡般地提高。IIS 6.0的內核體系主要建立在三個組件之上：W3SVC，http.sys，以及W3Core。

　　■ W3SVC
　　W3SVC也許是IIS 6.0體系中最不令人注意的元件，不過這並不說明它不重要。W3SVC的任務是根據配置資料的設置創建和監視工作線程，由工作線程運行Web網站應用。在IIS 5.0中，與IIS 6.0 W3SVC元件最接近的是IIS管理服務，IIS管理服務是Inetinfo的一部分；
-->
因此，如果Inetinfo出現問題，IIS管理服務也會出現問題，而且此時的IIS管理服務不能再重新啟動Inetinfo或其他故障的應用程式。在IIS 6.0中，W3SVC作為一個獨立的進程運行，Web應用的故障不可能波及W3SVC，因為W3SVC之內根本沒有第三方的代碼運行。W3SVC總是處於運行狀態，因此它能夠監視Web應用的健康狀況，並在必要時採取行動。由於這一策略，伺服器能夠根據用戶指定的參數監視和重新啟動應用程式。
　　■ http.sys
　　IIS 6.0體系設計中最重大的變化是加入了http.sys驅動程式，http.sys驅動程式的任務是處理HTTP請求，而且它在內核模式下執行操作。不要小看這一改變，將處理HTTP請求的任務從IIS 5.0、IIS 4.0的用戶模式改變到IIS 6.0的內核模式標誌著新一代IIS伺服器的誕生。
　　在Win 2K和NT 4.0中，IIS在用戶模式下運行。運行在用戶模式下的應用程式不直接與硬體通信，它們直接調用的是一些標準過程，這些標準過程或者將數據傳入內核模式的元件（例如網卡驅動程式，圖形子系統），或者調用內核模式元件的函數，以此完成保存檔、設置IP位址、將HTML檔發送到網路之類的任務。
　　用戶模式和內核模式之間的轉換是一項開銷很大的操作，伺服器首先從內核模式的TCP/IP棧將傳入的HTTP請求傳遞給用戶模式的Winsock，由Winsock將請求傳遞給IIS。從內核模式到用戶模式的切換很快發生，但不可避免地給處理過程帶來瞬間的延遲。當負載較大時，這種延遲不斷累加，同時由於這種轉換是必不可少的，所以管理員根本沒有辦法優化處理過程。
　　IIS 6.0的https.sys內核模式驅動程式極大地減少了用戶模式和內核模式之間的切換次數。http.sys監聽著HTTP請求，決定由哪一個用戶模式的進程來處理該請求，或者是否由驅動程式本身返回用戶請求的內容。
　　IIS 6.0在用戶模式下運行，完全依賴內核模式的http.sys作為接收用戶請求的伺服器引擎。因此，http.sys必須能夠在任何時候作出相應，必須具有極高的可靠性。用戶代碼可能導致進程出錯，所以微軟把http.sys設計成不執行任何用戶代碼，這樣，即使應用程式出現了故障，也不會影響到IIS 6.0本身，IIS 6.0仍能夠照常監聽HTTP請求。
　　如果要從內核模式的緩衝區返回靜態的應答，一個高速的、內核模式的、不允許運行應用程式碼的HTTP處理器是十分理想的，它減少了切換到用戶模式的昂貴開銷，能夠從內核模式的緩衝區快速返回應答。IIS 6.0的http.sys就管理著這樣一個緩衝區，而且使用了高度優化的啟發式緩衝區演算法來確定哪些內容要放入緩衝區，例如，http.sys可能只緩衝那些出現了一次以上請求的內容。
　　由於http.sys直接從應答緩衝區提取靜態內容，不必再切換到用戶模式，所以與IIS 5.0的性能相比，IIS 6.0的整體性能有了顯著提升。根據微軟的資料顯示，WebBench基準測試表明IIS 6.0返回靜態內容的速度要比IIS 5.0快150％。即使以IIS 5.0的隔離模式運行IIS 6.0伺服器（這時，IIS 6.0的體系結構與IIS 5.0的相似），同樣也能從http.sys驅動程式的應答緩衝區和其他改進之處獲益。
　　另外，微軟在http.sys驅動程式中採用了許多優化的演算法，使其能夠將請求直接轉發到適當的工作進程。在IIS 4.0和IIS 5.0中，必須通過多個步驟才能確定進程的哪一個實例擁有了應當接收當前請求的Web應用，但在IIS 6.0中，http.sys註冊了所有IIS 6.0應用，賦予每一個進程一個控制碼，IIS內部利用這些控制碼來標識註冊的應用程式要用到的一個或多個名稱空間。因此，當http.sys接收到一個HTTP請求，它能夠很快地將請求從內核模式的http.sys傳遞到正確的用戶模式的Web應用。
　　http.sys驅動程式還要執行其他一些任務，其中包括：
　　⑴ 將傳入的URL與各種長度、格式方面的規則進行比較。
　　⑵ 管理傳入請求的佇列。
　　⑶ 擔負著記錄IIS Web網站日誌資訊的任務（從而提高了記錄日誌的性能）。
　　⑷ 實施帶寬限制策略以及支援TCP/IP級的管理。
　　⑸ 實現客戶證書請求服務（但不支援安全套接字層——SSL）。
　　由於http.sys是一個作業系統的驅動程式，而不是一個IIS元件，因此該驅動程式的配置在註冊表而不是IIS配置資料中進行。當前，還有許多http.sys的註冊表設置項目尚無正式的說明文檔，它可能意味著微軟不鼓勵用戶修改這些設置，因為這些設置項目將來可能會有變化。http.sys驅動程式的註冊表設置專案位於
-->
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP下面，在這裏可添加各種註冊鍵（默認配置中不包含這些註冊鍵），諸如：  

　　⑴ EnableNonUTF8：如果加入EnableNonUTF8子鍵，並將它的值設置成0，http.sys只接受UTF-8編碼的URL。UTF-8的全稱是Universal Character Set（UCS）Transformation Format 8，這是一種字元集標準，標準全文在http://www.ietf.org/rfc/rfc2279.txt，它允許使用多國語言的字元集。默認情況下，EnableNonUTF8的值是1，表示IIS接受UTF-8、ANSI、雙位元組字元集（DBCS）編碼的URL。
　　⑵ PercentUAllowed：當這個子鍵設置成1時（預設值），http.sys認可那些部分字元用％uNNNN表示的URL，其中NNNN是一組表示實際字元的數位。當PercentUAllowed設置成0時，IIS 6.0將拒絕那些部分字元用這種方式表示的URL。
　　％uNNNN是一種不太常用的Unicode符號，不要將它與常見的UTF-8表示形式混淆。在UTF-8表示形式中，％20表示一個空格，例如http://www.iisanswers.com/new article.htm相當於http://www.iisanswers.com/new％20article.htm，兩者之間的轉換由IE流覽器自動完成，不管EnableNonUTF8和PercentUAllowed設置成了什麼值，IIS 6.0都會接受。
　　這兩項設置，再加上其他可以在IIS 6.0文檔中找到的設置項目，從一個側面反映了IIS 6.0在URL解析方面的改進。在IIS 5.0中，一些重大的安全問題與Web伺服器解析URL的方式有密切的關係，現在微軟終於解決了原先存在的缺陷，同時作出了一些改進，允許管理員更加明確地定義IIS 6.0解析URL的規則。在天生具有國際化特點的Internet上，多國語言並存，這些改進之處尤其具有重要意義。
　　關於Unicode的更多資訊，請參見http://www.unicode.org；關於IIS 5.0缺陷的更多資訊，請參見 http://www.wiretrip.net/rfp/p/doc.asp/i5/d57.htm。在Windows Server 2003 Resource Kit中可以找到一個幫助配置http.sys的工具。
　　■ W3Core
　　默認情況下，IIS 6.0在工作進程隔離模式下運行，如圖五所示。在這種模式中，對於每一個Web應用，IIS 6.0都用一個獨立的w3wp.exe的實例來運行它。w3wp.exe也稱為工作進程（Worker Process），或W3Core。

圖五

　　因此，工作進程隔離模式不存在進程內（In-Process）應用程式存在的問題，有效地提高了可靠性和安全性。可靠性的提高是因為一個Web應用的故障不會影響到其他Web應用，也不會影響http.sys，每一個Web應用由W3SVC單獨地監視其健康狀況。安全性的提高是由於應用程式不再象IIS 5.0和IIS 4.0的進程內應用那
-->
樣用System帳戶運行，默認情況下，w3wp.exe的所有實例都在一個許可權有限的“網路服務”帳戶下運行，如圖六所示，必要時，還可以將工作進程配置成用其他用戶帳戶運行。  

圖六
　　如果緩衝區溢出攻擊成功入侵了一個Web應用，攻擊者只能訪問當時運行工作進程的帳戶有權訪問的資源，默認的網路服務帳戶不能寫入Inetpub檔夾，執行許可權也極其有限，所以象CodeRed蠕蟲之類的攻擊根本不可能得逞。
　　某些Web應用，特別是有些Internet Server API（ISAPI）篩選器，在進程外運行時可能會遇到問題。在IIS 5.0和IIS 4.0中，ISAPI篩選器總是在Inetinfo之內運行，它們的設計目標本來就不是在進程外運行，正是由於這個原因，某些篩選器在IIS 6.0的工作進程隔離模式中運行時可能會出現問題——特別地，調用SF_READ_RAW_DATA或SF_SEND_RAW_DATA的篩選器尤其明顯。為此，IIS 6.0還提供了第二種操作模式，稱為IIS 5.0隔離模式。如果ISAPI篩選器不能在工作進程隔離模式下正常運行，在IIS 5.0隔離模式下應該沒有問題。在這第二種操作模式中，應用程式仍舊能夠從IIS 6.0的許多改進中獲益，例如http.sys驅動程式帶來的性能、可靠性的提高。
　　在IIS 6.0文檔中，可以看到一種叫做“應用程式池”的新特性。一個應用程式池包含一個或者一組工作進程，而且應用程式池是可以命名的。應用程式池可以從下列角度理解：在IIS 5.0中，我們可以將應用程式保護設置為低級（IIS進程）、中級（緩衝池）、高級（隔離），這個功能雖然很有用，但如果我們想要在一個池（一個dllhost.exe的實例）中運行兩個應用程式，在另一個池（另一個dllhost.exe的實例？）中運行另外兩個應用，該怎麼辦？IIS 5.0沒有提供命名dllhost.exe實例的途徑，因而也就不能將兩個特定的應用放入某個池運行。IIS 6.0的應用程式池允許指定名稱，如圖七，通過網站“屬性”對話方塊的“主目錄”頁，可以方便地將Web網站或目錄放入應用程式池。

圖七
　　四、應用程式池詳解
　　前面我們瞭解了IIS 6.0體系結構的關鍵元件，下面來看看有關應用程式池的一些問題。應用程式池的“屬性”對話方塊有四頁——回收，性能，運行狀況，標識，如圖六所示。在這些選項頁中，最引人注目的恐怕就是“回收”頁，使用該選項頁可以管理工作進程的回收。在工作進程隔離模式中，
-->
IIS可以配置成定期重新啟動應用程式池中的工作進程，從而更好地管理那些有錯誤的工作進程。這確保了池中的應用程式運行正常，並且可以恢復丟失的系統資源。為了回收工作進程，失敗工作進程接收請求的能力將被限制，直到它處理完存儲在請求佇列中的所有剩餘請求。為了排出當前請求，可以給予進程配置限制。同一命名空間組的替換工作進程在舊的工作進程停止前啟動，從而防止服務中斷。舊的進程完成其未決的請求，然後正常關閉，或者如果在達到了配置的時間限制、請求數、設置的時間計畫，或當達到指定的記憶體用量限制後仍沒有關閉，則明確地終止進程。默認情況下，應用程式池每隔1740分鐘（29小時）回收一次。
　　W3SVC根據“運行狀況”頁的選項來判斷應用程式池運行是否正常，包括：每隔指定的時間Ping工作進程，時間按秒計，預設值30秒；啟動時間限制（工作進程必須在指定的時間內開始）；關閉時間限制（工作進程必須在指定的時間內關閉）；是否啟動快速失敗保護（如果在指定的時間段內一定數目的工作進程發生失敗，則禁用應用程式池）。另外，ISAPI應用程式（包括ASP.NET和asp.dll）可以聲明自己不再適合提供服務，要求回收。
　　默認情況下，當IIS 6.0回收一個池時，它會使用一種稱為overlapped recycle的回收技術。在這種回收模式下，失敗的工作進程仍會保持運行狀態，同時創建一個新的工作進程。IIS 6.0把新傳入的請求傳遞給新的工作進程，但不拆除老的工作進程，直至老的工作進程處理完它佇列中的請求，或者遇到超時錯誤。在此期間，TCP/IP連接不會丟失，因為有http.sys保持著連接的有效性。當失敗的工作進程超時出錯時，下一個請求傳遞給工作進程的請求是新的請求，因此原來保存在進程中的會話資訊就會丟失。所有這類回收操作都自動進行，無需管理員干預，而且在大多數情況下，不會造成明顯的服務中斷現象。如有必要，可以將配置資料屬性LogEventOnRecycle的值設置為1，指示W3SVC執行回收操作時生成一條事件日誌記錄。
　　對於那些不能以多個實例運行的應用程式，overlapped recycle回收技術可能引起問題。如果遇到這類問題，可以將配置資料屬性DissallowOverlappingRotation的值設置成True（1），關閉某個應用程式池回收操作時的進程“重疊”現象。另外，對於失敗的工作進程，有時我們可能不想將它拆除，仍舊保留該進程，以便檢測和尋找發生問題的根源，這時可以將配置資料屬性OrphanActionExe設置成執行檔的名字，使得工作進程成為“孤兒”時執行檔仍保持運行狀態。
　　另一個與應用程式池有關的特性是，IIS 6.0允許將應用程式池配置成一個Web園（Web Garden）。要理解Web園的概念，可以設想這樣一種情形：假設有一個IIS 5.0伺服器和三個Web網站，每一個Web網站運行著相同的應用程式，如果IIS 5.0能夠自動按照圓形迴圈的模式將請求依次發送給這些功能上等價、實際上分離的Web網站，將負載分離到三個不同的進程，就可以構成一個小型的Web農場（Web Farm）——這就是Web園。
　　在IIS 6.0的Web園中，我們不必創建額外的Web網站，只要指定用於某個應用程式池的工作進程的數量就可以了。具體的配置步驟是：打開應用程式池的“屬性”對話方塊，轉到“性能”頁，在“Web園”下面的“最大工作進程數”輸入框中輸入進程數量，如圖八。當伺服器的負載較小，不需要額外的工作進程時，IIS 6.0在一定的時間後（默認20分鐘，可配置）自動縮減實際的工作進程數量；如果負載變大，需要額外的工作進程，IIS 6.0再次增加工作進程數量。這一切操作都自動進行，不需要管理員干預。

圖八
　　兩個新的配置資料屬性——SMPAffinitze和SMPAffinitzeCPUMask——允許配置為工作進程指派的特定處理器：將SMPAffinitized屬性設置成true表示應該把分配給應用程式池的特定工作進程指派給特定的CPU，SMPProcessorAffinityMask屬性用來配置十六進位的處理器遮罩，該十六進位處理器遮罩指出應用程式池中的工作進程應該綁定到哪個CPU。
　　寫到這裏，文章的篇幅似乎已經太長了。本文主要從體系結構的角度介紹IIS 6.0的新特性，並且盡力做到全面，至少要比通常見到的介紹更完善一些。文章的第二部分將涵蓋更多的IIS 6.0新特性，你會發現許多新特性正是自己長久以來盼望的。

文章來自: Tank部落格
引用通告: 查看所有引用 | 我要引用此文章
Tags:
相關日誌: